<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!-- 

This work is licensed under the Creative Commons Attribution 3.0 Unported License. 
To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ 
or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

-->

<html xmlns="http://www.w3.org/1999/xhtml">

<!--
START META-DATA 
-->
<head>
<title>Test Doubles: An Introduction To Unit Test Patterns</title>
<!-- metadata -->
<meta name="generator" content="S5" />
<meta name="version" content="S5 1.2a2" />
<meta name="author" content="Robert Burrell Donkin" />
<meta name="company" content="OpenTalkWare" />

<!-- configuration parameters -->
<meta name="defaultView" content="slideshow" />
<meta name="controlVis" content="hidden" />

<!-- style sheet links -->
<link rel="stylesheet" href="ui/default/slides.css" type="text/css" media="projection" id="slideProj" />
<link rel="stylesheet" href="ui/default/outline.css" type="text/css" media="screen" id="outlineStyle" />
<link rel="stylesheet" href="ui/default/print.css" type="text/css" media="print" id="slidePrint" />
<link rel="stylesheet" href="ui/default/opera.css" type="text/css" media="projection" id="operaFix" />

<!-- embedded styles -->
<style type="text/css" media="all">
/* Citations under blockquotes look well particularly styled */
div.cite {text-align: right; font-style: italic; font-family: monospace; font-size: smaller;}

/* Part header look well when similar to the fontispiece */
div.partition {font-size: larger;}
div.partition h1  {position: static; margin: 0.5em 0 0; padding: 0;
   font: bold 2em Helvetica, sans-serif; white-space: normal;
   color: #000; background: transparent;}
div.partition h2 {font: bold italic 1em Helvetica, sans-serif;}

/*  */
blockquote.about {margin: 2em 2em 3em 0em}
</style>

<!-- S5 JS -->
<script src="ui/default/slides.js" type="text/javascript"></script>

</head>
<!--
END META-DATA 
-->



<body>

<!--
START COMMON LAYOUT
-->
<div class="layout">
<div id="controls"><!-- DO NOT EDIT --></div>
<div id="currentSlide"><!-- DO NOT EDIT --></div>
<div id="header"></div>
<div id="footer">
<h1>Test Doubles: An Introduction To Unit Test Patterns</h1>
<h2>http://opentalkware.googlecode.com/svn/talk/TestDoubles/trunk/index.html</h2>
<h2><a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
<img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/80x15.png" />
</a>
&#8226; 
<a rel="tag" href="http://www.opentalkware.org/">
<img alt="OpenTalkWare" style="border-width:0" src="logo/opentalkware.png" />
</a>
</h2>
</div>
</div>
<!--
END COMMON LAYOUT
-->



<div class="presentation">


<!--
START PREFACE
-->
<div class="slide">
<h1>Test Doubles</h1>
<h2>An Introduction To Unit Test Patterns</h2>
<!-- 
START OPEN CONTENT ONLY
Derivative works which are not open content should remove the follow 
-->
<h4>This is OpenTalkWare</h4>
<!-- 
END OPEN CONTENT ONLY
-->

<div class="handout">
<!-- 
Document license
-->
<h4>License</h4>
<p>
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
<img alt="CC-BY" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/80x15.png" /></a>
This work is licensed under the Creative Commons Attribution 3.0 Unported License.
</p>

<h4>Attribution</h4>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
<p>
Based on
<span xmlns:dc="http://purl.org/dc/elements/1.1/" 
  href="http://purl.org/dc/dcmitype/Text" 
  property="dc:title" rel="dc:type">Test Doubles: An Introduction To Unit Test Patterns</span> 
  by 
<a xmlns:cc="http://creativecommons.org/ns#" 
  href="http://www.opentalkware.org" 
  property="cc:attributionName" 
  rel="cc:attributionURL">OpenTalkWare</a>
  The original source available
  from <a 
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    href="http://opentalkware.googlecode.com/svn/talk/" rel="dc:source">OpenTalkWare</a>
    is licensed under the
    <a rel="license" href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 Unported License</a>.
The original uses <a href='http://meyerweb.com/eric/tools/s5/'>S5</a> which is public domain. Please see the
<a href='http://www.meyerweb.com/eric/tools/s5/credits.html'>credits</a> for information about all the wonderful and 
talented contributors to S5!
</p>
<!-- 
END ATTRIBUTION
-->


<!--
ABSTRACT 
-->
<h4>Summary</h4>
  <p>
 An introduction to unit testing design patterns illustrated by
 an in depth look at Test Doubles (Dummies, Mocks, Fakes And Stubs).
  </p>
<h4>Abstract</h4>
  <p>
 Unit testing is a widely used agile technique. The basics can be learnt
 quickly but developers new to unit testing often struggle to create high 
 quality, maintainable tests. Design patterns describe a solution vocabulary
 for reoccuring concepts. They are widely used as tools to improve the 
 quality of object oriented designs. This talk introduces the pattern 
 language of the unit testing domain, illustrated by Test Doubles: 
 Dummies, Mocks, Fakes and Stubs (an area with many traps for the unwary).
  </p>
</div>

<div class='notes'>
  <ul>
    <li>
<strong>Level</strong> - 
Intermediary, knowledge of the mechanics of unit testing will be assumed
    </li>
  </ul>
</div>
</div>
<!--
END PREFACE
-->





<!-- 
###############################################################################################
#
#
# THE DRAMA OF TESTING
#
#
###############################################################################################
-->

<!--  
START OF SLIDE 
-->
<div class="slide">
<div class='partition'>
<h1>Part One</h1>
<h2>The Drama Of Testing</h2>
</div>

<div class='handout'>
  <p>
This section seems to offer a lighthearted introduction and motivate
the more formal catalog by use of metaphor but is a thinly veiled attempt
to use a little homour to make some deeper points.
  </p>
</div>

<div class="notes">
 <ul>
  <li>This is a talk of three uneven halves: Part One, Part Two And The Epilogue</li>
  <li>The transition between Part One and Part Two is a good place to take a break</li>
  <li>
  This talk was developed using <a href='#S5'>S5</a> which is a presentation system that uses
  only web standards (HTML, CSS and JavaScript). So it's available on 
  <a href='http://opentalkware.googlecode.com/svn/talk/TestDoubles/trunk/index.html'>online</a> 
  as well as on screen.
  </li>
  <li>
  The report view (available from the lower right hand corner) includes the accompanying text.
  Recommended for those who want to follow online (or who just want to appear knowledgable
  in front of their friends)
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>What Is A Unit Test?</h1>
<ul class='incremental'>
<li>?</li>
<li>...That's a good question</li>
</ul>
<div class='handout'>
  <p>
  It is conventional to start with something like this. 
  So here it is. But that's not really what this talk's
  about. Answer not included.
  </p><p>
  This the start of a running gag with a serious side.
  Describing a unit test is easy but definition is not.
  Though there's agreement about the core, the edges
  are definitely blurred.
  </p><p>
  This perspective leads to an emphasis on process, not
  product. When <em>Driven Development</em> (of whatever
  flavour) was young - and the concepts felt novel - this
  was important. Now, there is a beginning of a backlash
  against the process due - in most part - to bad technique.
  </p>
</div>

<div class="notes">
 <ul>
  <li>One of the themes of this talk is that developers too often write tests 
      without investing thinking time. The habit of TDD by joining the dots
      is easy to slip into: <em>one test case for a class, and one test per method</em>.
      Reread <a href='#testdrivendevelopment'>Test Driven Development</a>, this time
      paying attention to the skill used to select the examples. Few objects in the wild
      will require as little setup.
  </li>
  <li>Throwing open this question works well</li>
  <li>This talk aims to encourage interaction. Good to start early.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>What Is This Talk About?</h1>
<blockquote class='about'
<p class='incremental'>
This is a talk about the tests that developers write, <br/>
and how - as developers - we can write better tests.
</p>
</blockquote>
<div class='handout'>
  <p>
  Instead, let's concentrate on the function of this talk.
  </p><p>
  It assumed too often that fantastic coders just need to be
  asked and will write great tests with no experience of the domain
  necessary. Writing high quality test code is challenging and
  skills improve with practice and experience. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>It's about technique</li>
  <li>
Most people associate <em>Test Double</em> with <em>Behaviour Driven Development</em>.
So, talking about <a href='#mockobjects'>Mock Objects</a> is a place to start.
Many people find <em>Mocks</em> difficult, but this is part of wider problems
with doubles and are easier to understand as special cases.  
  </li>
  <li>
It's not unusual for developers to feel a little iffy and unsure about
<a href='#behaviourverification'>Behaviour Verification</a>. This is understandable but
- as a technique - it is an important one. Typically, it is used less frequently than
<a href='#stateverification'>State Verification</a> but mastering in context allows
judicious use when other techniques would result in poor quality tests.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Why...?</h1>
<ul class='incremental'>
<li>Why Do Developers Test?</li>
<li>Why Do Developers Automate Tests?</li>
<li>And What Is A Unit Test...?</li>
<li>...Maybe Later...</li>
</ul>

<div class='handout'>
  <p>
Developers test. Creating perfect code first time, every time is a rare
gift indeed. Most developers make mistakes - and usually plenty of mistakes.
So, most developers do some testing of the code they write before it ships.
  </p><p>
Though testing is as old as programming, test automation by developers is newer. 
There are many reasons why developers automate tests. For example, it's easier and
quickly to rerun an automated test than a manual one.
  </p><p>
And another chance to air the running gag.
  </p>
</div>

<div class="notes">
 <ul>
  <li>An early opportunity for answers from the audience.</li>
  <li>Don't really want to spend too much time in this talk
  on the basics of unit testing though some lead is justified.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<blockquote>
<p>
This is a talk about the tests that developers write, <br/>
and how - as developers - we can write better tests.
</p>
</blockquote>
<ul class='incremental'>
  <li>What Is A Design Pattern?
    <ul class='incremental'>
      <li>A reusable design structure</li>
      <li>(Not a good definition but short)</li>
      <li>We'll return to this later</li>
    </ul>
  </li>
  <li>Design Patterns Create A Language</li>
</ul>
<div class='handout'>
  <p>
  There are plenty of ways that <a href='#designpatterns'>Design Patterns</a> are
  characterised but not one good short definition. But one isn't really for this 
  talk, and a reasonable treatment would be a talk in itself.
  </p><p>
  The following is given later:
  </p>
<blockquote>
<p>
"A design pattern names, abstract, and identifies the key aspects<br/> 
of a common design structure that make it useful<br/>
for creating a reusable object-oriented design."
</p>
</blockquote>
<div class='cite'><p><a href='#designpatterns'><cite>Design Patterns</cite></a></p></div>
  <p>
  The usage that <em>Design Patterns</em> are put to in this talk is not the one
  that's conventionally used to motivate them. The perspective is more liguistic
  than prescriptive.
  </p><p>
  A meaningful discourse requires a shared language. A technical discussion
  requires that we agree a precise vocabulary. As demonstrated by difficulties
  with loose terms like <em>Unit Test</em>, developers need to start moving towards a
  better technical vocabulary. 
  </p><p>
  Studying design patterns in the unit testing domain can help to introduce an appropriate
  technical vocabularly by naming and abstracting the most common design structures. This
  is the perspective that this talk will use. Patterns will be established and motivated
  as a means to understanding the tests that developers write, and so how these tests
  can be improved by refactoring.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Another good chance for audience participation</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF SLIDE 
-->
<div class="slide">
<blockquote>
<p>
This is a talk about the tests that developers write, <br/>
and how - as developers - we can write better tests.
</p>
</blockquote>
<ul class='incremental'>
<li>Product Not Process</li>
<li><strike>Test Driven Development</strike></li>
<li><strike>Behaviour Driven Development</strike></li>
<li><strike>Need Driven Development</strike></li>
</ul>

<div class='handout'>
  <p>
  This talk is about the product: the tests developers write, and not
  the process. Though process helps to explain some of the history,
  too often it fails to assist comprehension of the product. 
  </p><p>
  Process may well drive the choice of technique, too often practitioners
  lacking a comprehensive understanding of technique attempt to use a
  single tool for every job. Too often, lack of technique contributes
  to problems with process. 
  </p><p>
  It's important for the whole team to be able to discuss technique. Those 
  wearing management and testing hats need to be able to involve themselves
  in improving the effectiveness of testing. They also need to be able to 
  assess where education and training in testing techniques is required.
  </p><p>
  It's also important for all developers in the team to level upwards in
  terms of testing techniques. Writing tests is a cross cut skillset -
  those with more experience in development and design may be inexperienced
  with testing techniques used by others. 
  </p><p>
  This is where those wearing the testing hat can often make an effective 
  contribution by demonstrating leadership and disseminating their skills.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Change for audience participation: ask about how knows each process.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->








<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>What Is Testing?</h1>
<ul class='incremental'>
<li>And What Is A Unit Test?</li>
</ul>

<div class="notes">
 <ul>
  <li>Let's try for another cheap laugh</li>
  <li>This marks a transition between a preamble aimed at warming the
  audience up and reminding everyone about some concepts that'll be used,
  and the first main exposition.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Testing Is A Drama</h1>
<blockquote>
<p>
"All the world's a stage,<br/>
And all the men and women merely players:<br/>
They have their exits and their entrances;<br/>
And one man in his time plays many parts"
</p>
</blockquote>
<div class='cite'><p><cite>William Shakespeare, As You Like It</cite></p></div>

<div class='handout'>
  <p>
A drama is a useful metaphor for a test. It is a good aid for understanding
the roles that <a href='#testdouble'>Test Doubles</a> and will illustrate the qualities
in place of code examples. 
<p>
This quote is a good starting point:
</p>
<blockquote>
<p>
The Test is just a stage,<br/>
And all the objects merely players:<br/>
They have their exits and their entrances;<br/>
And one instance in it's time plays many parts<br/>
</p>
</blockquote>
<div class='cite'><p><cite>With Apologies to The Bard</cite></p></div>
<p>
This metaphor offers some valuable insights. A test should convey a story
about the objects involved. When testing is a struggle, return to this metaphor
and ask: <em>what is the story and what roles are the objects playing within it?</em>
</p>
</div>

<div class="notes">
 <ul>
  <li>Rather than using code examples, this metaphor will form an illustration</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>The Stunt Man Analogy</h1>
<p>A Test Double Is Like A Stunt Man</p>
<ul class='incremental'>
  <li>A Stunt Man substitutes for an actor</li>
  <li>A Test Double substitutes for an authentic component</li>
</ul>

<div class='handout'>
  <p>
This analogy is the conventional introduction to <a href='#testdouble'>Test Doubles</a>.
It is a useful way to comprehend the basic idea but to understand some of the subtleties,
other metaphors are needed.
  </p><p>
An analogy that's sometimes used for a <em>Test Double</em> is a stunt man. This fails
to convey some of the subtleties but it's a reasonable place to start. In a film, when 
a dangerous stunt is required, the actor may be substituted by a stunt man
who - more or less - resembles the actor. 
  </p><p>
So, in a test, a <em>Test Double</em> substitutes for the authentic component.
The <em>Double</em> presents an API that resembles an authentic component and is
used - in the test - where the original is unsuitable. There are various reasons
why a development might want to make this change. To explore these, we need to switch
metaphor.
  </p><p>
  </p>
</div>

<div class="notes">
 <ul>
  <li>Audience participation: ask for reasons</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>A Test Is A Drama</h1>
<ul class='incremental'>
<li>Tell A Simple Story...</li>
<li>...But tell it well.
  <ul class='incremental'>
    <li>Each test should precisely verify a single quality</li>
    <li>Prefer fixtures to composite tests</li>
    <li>Factor into short methods</li>
  </ul>
</li>
<li>Communicate Intent
  <ul class='incremental'>
    <li>Test names should say <em>Why</em> not <em>What</em></li>
    <li>Choose good names for field and variables</li>
    <li>Comment <em>How</em></li>
  </ul>
</li>
</ul>

<div class='handout'>
  <p>
Overelaboration lies at the heart of most tests which are hard to comprehend. Typically,
to avoid factoring out a common fixture, quality after quality is tested (and often retested) 
within a single case. A test created when wearing a developer's hat should tell a 
simple story but tell it well. Every test should follow the same simple pattern:
  </p>
  <ol> 
    <li>Setup</li>
    <li>Exercise</li>
    <li>Verify</li>
  </ol>
  <p>
Sounds easy, and so it is. But it's easier to slip into bad habits - adding another
round of exercisement and verification rather than factoring out a new test specifically
to test that new quality.
  </p><p>
This is not to say that scripted tests are wrong - they are vital but they are not
the same. Scripted tests should be developed with the <em>test professional</em> hat on,
working from the user story perspective. They are often better developed using different
technologies. However, this is all out of the scope so let's leave it there.
  </p><p>
Testing a single quality well is not enough. A test needs to communicate it's intent: 
to explain the quality under trial. 
  </p><p>
Good naming is crucial. In any simple, high quality test <em>what</em> is exercised should be clear
from the code. Insight into the intention of the test - the <em>why</em> is not.
The developer needs to ensure that the intention is communicated.
  </p><p>
The name of the test should communicate the intent. Avoid naming a test from the method exercised. 
Instead, use a sentence which describes the intent. Use the method comment to tie the intent
into the design documentation and user stories.
  </p><p>
Choose good names for fields and variables. Any modern IDE can indicate the nature of an object. 
It cannot indicate the role that it is intended to play nor the character built in fixture setup. 
The name needs to do that. Thinking about the test as a drama will help improve the quality 
of these names.
  </p><p>
Use in-code comments to indicate <em>how</em> the test proposes to go about it's business.
A reader should be able to comprehend at a glance <em>how</em> a test works but too often,
the details obscure this. So, factor them into methods and use in-code comments to explain 
what's going on in all other cases. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>Prefer numerous short, focussed tests over a single long unfocussed one</li>
  <li>Avoid <em>join-the-dots</em> TDD - think about intents linked to qualities in user stories 
  or design documents rather than obsessing about a test per method. The best way to ensure good 
  coverage is to measure it</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Enter The Champion</h1>
<ul class='incremental'>
  <li>Every Tale Needs A Hero</li>
  <li>Every Test Needs A Subject
  <li>Let Everyone Know Who's The Hero</li>
</li>
</ul>

<div class='handout'>
  <p>
<em>System Under Test</em> is - in general - preferred to <em>subject</em>. A test might focus
on a component where a system of objects collaborate to create a particular result. In practice,
most tests focus on a single object perhaps the facade to the system.
<em>subject</em> is shorter and easier on the mouth, and will be used synonymously.
  </p><p>
Understanding which is the system under test is crucial to the comprehension of a test.
Readers should not have to remember the name of the test or look back at the setup of the
fixture to understand which object is the subject. Adopt a simple logical naming convention
- call the system under test <em>subject</em> or <em>systemUnderTest</em>, say - and make
sure every test sticks to it.
  </p><p>
Thinking about the <em>subject</em> as the hero of a drama helps to appreciate the 
central nature of this role. The test is about the subject, and should verify only 
the subject as it interacts with the other objects. A test will be 
<a href='#fragiletest'>fragile</a> if changes in behaviour of these other objects
cause tests of the <em>subject</em> to fail. 
</p><p>
This is one way that <em>Test Doubles</em> are often used. Using a double in the test
allows the behaviour to be isolated from the authentic original. When using doubles
in this ways, it is crucial to focus on the intent of the test and decide which 
interactions are relevant to that intent. It may be tempting to verify other qualities
so that the test will fail when either player deviates from the script but this is 
a classic cause of <em>Fragile Tests</em> when using <em>Test Doubles</em>.
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  The subject will never be a <em>Test Double</em> but when it comes to the supporting cast,
  many roles may well be filled by them.
  </li>
  <li>
  Being unsure which object is the subject is a clear sign that the test is overlarge, and will
  be confusing to readers. Break it down into smaller tests.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>And Introducing</h1>
<ul class='incremental'>
  <li>The Supporting Cast</li>
  <li>All Those Other Objects
    <ul class='incremental'>
      <li>Think About Roles...</li>
      <li>...And communicate them clearly</li>
      <li>Names Follow Role Not Nature</li>
    </ul>
  </li>
  <li><em>Test Doubles</em> may substitute for any member of the cast
    <ul class='incremental'>
       <li>Communicate clearly the role each is playing</li>
    </ul>
  </li>
</ul>

<div class='handout'>
  <p>
It is rare that good test coverage can be achieved by a monologue involving the subject alone.
Testing complex objects may involve a cast of dozens.
  </p><p>
Thinking about the roles filled by these supporting objects will help to write tests
which are less fragile and more comprehensable: in short, more maintainable. In most cases, the role
filled by a member of the supporting cast will map well to an existing pattern. This should
lead to an understanding of the tradeoffs inherant and to a good naming scheme.
  </p><p>
Understanding a test with a large cast takes time. But unhelpful naming of fields and variables
turns this chore into a difficult problem. Any modern IDE will be able to easily inform the user
of the nature of an object. It cannot communication intent. The role that the object plays 
should be communicated in detail by the name. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  When a natural mapping does not appear, this should be a warning sign. Perhaps the test is overambitious
and could be refactored into several simpler tests. Perhaps, the intention of the test in the developer's
mind is not sufficiently clear, and a rethink would be useful. Perhaps a <a href='#xunittestpatterns'>book</a>
needs to consulted. 
  </li>
  <li>
If this is one of rare erratic cases, then extra documentation and care should be invested to ensure
that the reader understand the design approach taken.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>The Roles Objects Play</h1>
<h2>Dummies</h2>
  <ul class='incremental'>
    <li>Extras</li>
    <li>Verifying Interactivity Is Not The Intention</li>
  </ul>

<div class='handout'>
  <p>
Time to take a deeper a look at common roles, and introduce the <em>Test Doubles</em>
patterns associated with them.
  </p>
  <p>
A dummy is just part of the scenary. It is not called upon to interact with the protagonists but is
need to be there. A <em>Dummy Object</em> is a <em>Test Double</em> that just plays the role of a 
place holder. If the authentic object is slow or difficult to create then substitution is generally
a good idea.
  </p><p>
Verifying interactivity with a dummy is not the intention of the test. So, it is safe to fix
any breakages which occur by simply ensuring that the dummy does not fall down. So, it's best to clearly
indicate any <em>Dummy</em> instances through naming.
  </p><p>
An actor may interact with an extra: play off them. A good extra will take this in their stride.
In a test, whenever a <em>Dummy</em> is used, it needs to respond reasonably to novel interactions. 
By definition, all interactions with the <em>Dummy</em> are outside the scope of the test.
If the intent of the test is to demonstrate that no interaction occurs then a dummy should not be used.
Interactions unforeseen when the test was created should not result in a test failure.
  </p>
</div>

<div class="notes">
 <ul>
  <li>
<a href='#mocktools'>Mock Toolkit</a>'s are an easy way to create a <em>Dummy</em> 
(more about these later).
Most toolkits default to verification of all behaviour. This will result in a 
<a href='#fragiletest'>Fragile Test</a> where any novel interaction with the dummy 
will result in a test failure. Learn how to alter this default before using
the toolkit to create <em>Dummies</em>.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->










<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>The Roles Objects Play</h1>
<h2>Stubs</h2>
  <ul class='incremental'>
    <li>Minor characters</li>
    <li>Stubs feed indirect input to the subject</li>
    <li>Stubs should not upstage the stars</li>
    <li>Comment <em>How</em></li>
  </ul>

<div class='handout'>
  <p>
  Stubs should not upstage the stars. They exist just to ensure that the subject is fed with the 
  correct stimuli required by the test. Otherwise, they should robustly handle behaviour change.
  </p><p>
  Since stubs play an important role in the test, they should be readily identifiable through naming.
  The input fed - and it's purpose - should also be clearly communicated. So, comment the 
  <em>How</em> in-code.
  </p><p>
  In a drama, the minor characters should not upstage the stars. They have lines to feed to the
  main protagonists but should not break down when the stars respond in novel ways. In a test,
  <em>Stubs</em> are there to feed indirect inputs to the system under test. They should not
  attempt to verify the behaviour of the subject. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  Substituting authentic stubs by a <em>Test Double</em> is very common for a variety of reasons.
  This is a good chance for audience participation.
  </li>
  <li>
<a href='#mocktools'>Mock Toolkits</a> (more about these later) are an easy way 
to create a <em>Stub</em>. Most toolkits default to verification of all behaviour. 
This will result in a <a href='#fragiletest'>Fragile Test</a> where any novel interaction 
with the <em>Stub</em> will result in a test failure. Learn how to alter this default before using
the toolkit to create <em>Stubs</em>.
  </li>
  <li>
A test should verify either <a href='#behaviourverification'>behaviour</a> 
or <a href='#stateverification'>state</a> but not both
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>The Roles Objects Play</h1>
<h2>Mocks And Spies</h2>
  <ul class='incremental'>
    <li>Major Protagonists</li>
    <li>Observe the behaviour of the subject
        <ul class='incremental'>
          <li>Used for <a href='#behaviourverification'>Behaviour Verification</a></li>
          <li>Mock Or Stub? An object may play different roles...</li>
        </ul>
    </li>
  </ul>
</li>
</ul>

<div class='handout'>
  <p>
Mocks and spies differ in their approach to verification. Mocks are loaded 
with expectations during the test setup which they verify as the subject is
exercised by the test. Spies simply record interactions. In the verification
phase of the test, the records can be checked by the test.
  </p><p>
It is quite common that a mock or a spy will need to act as a stub, supplying
indirect stimulation to the subject. This is a frequent cause of confusion.
Tests which do not clearly communicate which interactions are intended to be
verified and which are just exercise the <a href='#sut'>subject</a> 
  </p>
</div>

<div class="notes">
 <ul>
  <li>Before using a <a href='#mocktools'>Mock Toolkit</a>, learn how it can generate
  <em>Stubs</em> and <em>Dummies</em> which do not verify behaviour. If it cannot, 
  raise a bug and ensure other usages are very well documented.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>But What Is A Unit Test?</h1>
<ul class='incremental'>
<li>Back with the catalog after the break...</li>
</ul>

<div class="notes">
 <ul>
  <li>Ho Ho Ho</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!-- 
###############################################################################################
#
#
# CATALOG
#
#
###############################################################################################
-->
<!--  
START OF SLIDE 
-->
<div class="slide">
<div class='partition'>
<h1>Part Two</h1>
<h2>Catalog</h2>
</div>

<div class='handout'>
  <p>
  Thanks to  <a href='#xunittestpatterns'>xUnit Test Patterns</a>. This talk
  can only cover a small portion of the material. Buy the book.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Perhaps a little break before a little more formality</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='designpattern'>Design Patterns</a></h1>
<blockquote>
<p>
"A design pattern names, abstract, and identifies the key aspects<br/> 
of a common design structure that make it useful<br/>
for creating a reusable object-oriented design."
</p>
</blockquote>
<div class='cite'><p><a href='#designpatterns'><cite>Design Patterns</cite></a></p></div>
<ul class='incremental'>
<li>Not everything is a pattern</li>
<li>Not everything in this catalog is a pattern</li>
</ul>

<div class='handout'>
  <p>
The second part of this talk is based around the pattern catalog for
testing described in <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a>.
It's good to start by reading (again) a description of a <cite>Design Pattern</cite>
given by the Gang Of Four.
  </p>
  <p>
To talk about the tests that developers write, and how - as developers - we can write 
better tests. Design patterns are essential but not sufficient. There is quite a 
quantity of vocabulary of different sorts that is needed.
  </p>
  <p>
There are a number of technical terms that must be agreed. Many of these are 
reasonably controversial, so it's worth stopping and talking about them to
avoid later confusion.
  </p>
  <p>
Not every pattern is positive. An anti-pattern indicates a pattern to be avoided.
  </p>
</div>

<div class="notes">
 <ul>
  <li><a href='#designpatterns'><cite>Design Patterns</cite></a> by the Gang Of Four 
is a book that every developer should own. 
  </li>
  <li>
  <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a> is the seminal
  reference on understanding and troubleshooting development tests. A great investment 
  for any agile organisation.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Code Smells</h1>
<blockquote>
<p>
"A code smell is a surface indication that usually corresponds to a deeper problem in the system"
</p>
</blockquote>
<div class='cite'><p><a href='#codesmells'><cite>Code Smells</cite></a></p></div>

<blockquote class='incremental'><p>If it stinks, change it.</p></blockquote>
<div class='cite'><p class='incremental'><a href='#refactoring'><cite>Grandma Beck</cite></a><p></div>

<ul class='incremental'>
<li>A smell doesn't always indicate something's wrong...</li>
<li>...but usually does</li>
</ul>

<div class='handout'>
  <p>
Code smells are neither patterns nor anti-patterns. They are not design structure
reusable for good or ill. Code smells are not quite specific enough to be 
diagnostic symptoms either: they are general symptoms which - when usually
observed - indicate that there's a problem buried somewhere or other. 
  </p><p>
Tracking down the root cause is sometimes easy, sometimes hard. It's not 
unusual for a single cause to give rise to several smells. 
  </p><p>
There is a temptation to leave bad smells alone. Intuition says
that there's something not right but - as a developer - you can probably
justify it being someone else's problem. 
  </p><p>
This makes it a problem for
management: it's commonly observed that a problem will smell fishy for
quite a while before it finally becomes critical and necessitates
action. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>For more, see
    <ul>
      <li><a href='#codesmells'>Code Smells</a> (short)</li>
      <li><a href='#refactoring'>Refactoring</a></li>
      <li><a href='#xunittestpatterns'>xUnit Test Patterns</a> (comprehensive)</li>
    </ul>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->















<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='sut'>Term: System Under Test</a></h1>
<blockquote>
<p>
"Software developers will probably find the term 'system under test' ... unfamiliar.<br/>
It is short for 'whatever thing we are testing'."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Abbreviated as SUT</li>
  <li>But <code>subject</code> often works better when naming variables</li>
  <li>A test should clearly communicate the identity of the SUT</li>
</ul>
<div class='handout'>
  <p>
  A shorter name often preferrable to developers is <code>subject</code> or <code>subjectOfTest</code>.
  This is most appropriate for finely grained tests which focus exclusively on a primary
  class. 
  </p>
  <p>
  Choosing good variable names means tests are more readable and maintainable. It is often not
  immediately obvious from the context which object is the <abbr title='Subject Under Test'>SUT</abbr>.
  Naming the variable referencing the SUT <code>subject</code> or <code>systemUnderTest</code> makes
  this immediately clear to the reader.
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  When it starts becoming unclear which is the <em>subject</em> of the test, 
  the test is probably overelaborate. Consider breaking it down.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='doc'>Depended-On Component</a></h1>
<blockquote>
<p>
"An individual class or a large-grained component on which the system under test (SUT)
depends."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
<li>Abbreviated to DOC</li>
<li>Not all DOCs are created equal</li>
<li>Understanding a test means understanding the DOCs</li>
</ul>

<div class='handout'>
  <p>
When a subject is exercised, it interacts with the DOCs. The DOCs are crucial to any automated
test. Most objects created in a test are DOCs and find themselves playing different roles.
Careful naming indicates quickly to a reader the role the DOCs plays in the test,
an so is essential. A good understand of test patterns makes good naming easier.
</p>
</div>

<div class="notes">
 <ul>
  <li>Test doubles are DOCs.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->










<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='fixture'>Term: Fixture</a></h1>
<blockquote>
<p>
"All the things we need to have in place to run a test and expect a particular outcome."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Invest in good fixtures</li>
</ul>
<div class='handout'>
  <p>
  <em>Fixture</em> is one of those terms that's hard to define well. Different people and different tools
  use it with subtly different shades of meaning. Following 
  <a href='#xunittestpatterns'>Gerard Meszaros</a>, this talk uses it to mean the <em>test context</em>.
  Those familar with <a href='#nunit'>NUnit</a> may find this usage a little unnatural.
  </p>
  <p>
  A good fixture is an investment. It is usually easier and quicker just to throw a load of
  dissimilar tests together by cut'N'paste. 
  </p>
  <p>
  A good fixtures pays for itself by consolidating the context into an easily readable common setup
  for a group of tests which not only test the same subject but the same general context as well. 
  This usually allows permutations and variations to be added easily, and the fixture to be more 
  readily malleable.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Tests which have similar setups should be grouped together</li>
  <li>When more setup happens in the test method than in the setup for the test class,
  it's time to split the test class.</li>
 </ul>
</div>

</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='stateverification'>Pattern: State Verification</a></h1>
<blockquote>
<p>
"How do we make tests self-checking when there is state to verify?<br/>
We inspect the state of the system under test after it has been exercised
and compare it to the expected state."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ol class='incremental'>
  <li><a href='#fixture'>Fixture</a> is setup</li>
  <li><a href='#sut'>Subject</a> is exercised</li>
  <li><a href='#sut'>Subject</a>'s state is verified</li>
</ol>

<div class='handout'>
  <p>
  This is the most frequently used verification strategy. 
  </p>
  <p>
  There are a couple of notable variations covered in depth in 
  <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a>. They differ
  in their approach to accessing the final state of the subject.
  </p><p>
  <cite>Procedural State Verification</cite> is probably the most familiar. Here,
  repeated method calls are to make to discover the state.
  </p><p>
  <cite>Expected State Specification</cite> compares the subject with a instance
  populated with the expected values. This leads to shorter assertions though 
  sometimes the required fixture is complex. This is one area where a 
  <a href='#testdouble'>Test Double</a> may be used.
  </p>
</div>

<div class="notes">
 <ul>
  <li>This is the style make famous by <a href='#testdrivendevelopment'>Test Driven Development</a>.
Read it.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='behaviourverification'>Pattern: Behaviour Verification</a></h1>
<blockquote>
<p>
"How do we make tests self-checking when there is no state to verify?.<br/>
We capture the indirect outputs of the SUT as they occur and compare them 
to the expected behaviour."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Checks interactions, not state</li>
  <li>Typically some sort of <a href='#testdouble'>Test Double</a> is used</li>
</ul>
<div class='handout'>
  <p>
  Bahaviour verification checks the interactions between the subject and it's depended-on 
  components. There are some important functions whose effect is not to change the state
  of the object but to choreography a sequence of interactions. Inspecting the state
  won't work in these cases.
  </p><p>
  Behaviour verification almost always uses some kind of <a href='#testdouble'>Test Double</a>.
  And quite often of many kinds. Unless the creator of the test is careful to commuicate
  clearly which behaviour is involved in verification, which in stimulation and which are
  just scenary, behaviour verification can easily lead to 
  <a href='#hightestmaintenancecosts'>High Test Maintenance Costs</a>.
  </p><p>
  There are a couple of notable approaches to behaviour verification.
  </p><p>
  <cite>Procedural Behaviour Verification</cite> captures method calls during
  the interaction, and inspects them at the end.
  </p><p>
  <cite>Expected Behaviour Verification</cite> is configured with a description
  of the required interactions and checks them as the test proceeds.
  </p>
</div>

<div class="notes">
 <ul>
  <li><abbr title='Behaviour Driven Development'><a href='#bdd'>BDD</a></abbr> 
  played a similar to that played by <abbr title='Test Driven Development'>TDD</abbr>
  in the evolution of state verification
  </li>
  <li>
  Behaviour verification is less familiar to most developers than state verification.
  Poor quality tests have a high long term cost. A general lack of practice means
  that organisations starting to use behaviour testing should ensure they set
  training time aside.
  </li>
  <li>
  There are quite a number of <a href='#mocktools'>libraries</a> for behavioural
  testing. Everyone seems to have their own favourite.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->



<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='hightestmaintenancecosts'>Project Smell - High Test Maintenance Cost</h1>
<blockquote>
<p>
"Too much effort is spent maintaining existing tests."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>
  A key issue for Agile project management
  </li>
  <li>Common causes:
    <ul class='incremental'>
    <li>Hard-To-Test Code</li>
    <li><a href='#testcodeduplication'>Test Code Duplication</a></li>
    <li><a href='#fragiletest'>Fragile Test</a></li>
    <li><a href='#obscuretest'>Obscure Test</a></li>
    </ul>
  </li>
</ul>

<div class='handout'>
  <p>
  It's very easy for this to go unnoticed until it is too late. It's only clear that tests
  are unmaintainable when the time spent debugging existing tests drags development velocity
  down terminally. By this stage, it's too late - the system is overspecified and fixing
  this is going to be expensive.
  </p>
  <p>
  This is a particular problem for Agile projects with short development cycles.
  </p>
  <p>
  Hard-To-Test code is one area that <cite><a href='#testdouble'>Test Doubles</a></cite>
  have an important role to play. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>When existing tests have to be debugged, this smells as if the original
  test quality was not good enough</li>
  <li>Managers need to activity monitor the amount of time spent modifying existing tests</li>
  <li>Leaders need to actively monitor the quality of test code</li>
  <li>Developers need to be able to feed information back up the chain</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='testcodeduplication'>Code Smell - Test Code Duplication</a></h1>
<blockquote>
<p>
"The same test code is repeated many times."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Caused by:
    <ul class='incremental'>
      <li>
  Lazy Test Coding
      </li>
      <li>
  Enthusiastic Repetition
      </li>
    </ul>
  </li>
  <li>Leads to:
    <ul class='incremental'>
      <li><a href='#fragiletest'>Fragile Tests</a></li>
      <li><a href='#obscuretest'>Obscure Tests</a></li>
    </ul>
</ul>

<div class='handout'>
  <p>
  The typical way that these problems arises is by a failure to factor out common code. 
  </p>
  <p>
  Poor quality code with lots of cut'N'paste repetition is just as harmful in test code
  as it is in production code. When changes need to be made to the system, all that code 
  is going to need to be review and updated. This is a key development quality issue
  that needs to be quickly address before it leads to <cite><a href='#hightestmaintenancecosts'>
  High Test Maintenance Costs</a></cite>. Investing in good <cite><a href='#fixture'>Fixtures</a>
  </cite> by factoring out common code in the fixture is crucial.
  </p>
  <p>
  At first glance, it might seem that more tests must be better but code coverage cannot 
  be improved by repeated verification of the same quality. Every repeated verification is
  another place that need to be changed if that function is modified. So, this has a 
  maintenance cost.
  </p>
  <p>
  Behind <cite>Test Code Duplication</cite> is usually an education or a time issue. 
  When time is an issue, selectively coding a small number of carefully chosen high 
  quality tests usually results in adequate coverage without the maintenance problem 
  that rushing off a quantity of poor quality tests almost always creates. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>These issues are often found together in tests which try to compensate for quality 
  with quantity</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='fragiletest'>Behaviour Smell - Fragile Test</a></h1>
<blockquote>
<p>
"A test fails to compile or run when the SUT is changed in ways 
that do not affect the part the test is exercising."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
<li>Fragile Tests lead to <a href='#hightestmaintenancecosts'>High Test Maintenance Costs</a></li>
<li>Two (Of The Many) Causes:
  <ul class='incremental'>
    <li>Overspecified Software</li>
    <li>Interface Sensitivity</li>
  </ul>
</li>
</ul>

<div class='handout'>
  <p>
  <cite>Fragile Tests</cite> are almost worth a talk in themselves. Read 
  <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a> for a comprehensive
  treatment. There are two causes which have direct relevance.
  </p><p>
  One trap when using <cite><a href='#behaviourverification'>Behaviour Verification</a></cite>
  is to couple the test too deeply with the particular implementation. It fixes in detail
  not just <em>what</em> the object should do but specifies exactly <em>how</em> it
  should achieve it. Any change to the implementation will result in a broken test.
  This is <cite>Overspecified Software</cite>.
  </p><p>
  Tests should attempt to pick out key qualities to verify. To avoid overspecification,
  it is crucial to pick out the important interactions worthy of verification. A small
  number of key actors should play the major roles. The others consist of minor parts 
  and extras. These should just be used to feed lines to the chief protagonist,
  with only the most important behaviour being verified. This allows the interactions
  between the other objects and the subject to be modified without breaking the test.
  </p>
</div>

<div class="notes">
 <ul>
  <li>A common problem with <cite>Overspecified Software</cite> is that it's hard to
  understand what exactly is being tested. Verifying unimportant implementation details
  makes it hard to pick out the crucial required behaviours.
  This leads to <a href='#obscuretest'>Obscure Tests</a> as well as <code>Fragile Test</code>.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='obscuretest'>Code Smell - Obscure Test</a></h1>
<blockquote>
<p>
"It is difficult to understand the test at a glance"
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
<li>
Do the basics well
</li>
<li>A test is a drama so tell the story</li>
</ul>

<div class='handout'>
  <p>
  Readability is the key to efficient test maintenance. A good test should communicate precisely 
  which qualities are tested and how they are. 
  </p><p>
  This starts with the simple things like choosing good names for methods, variables and fields.
  It should not be necessary to read the setup code to understand the nature of each subsidary
  object and the role that it is intended to play.
  </p><p>
  Invest in good fixtures and don't be afraid to break out tests with dissimilar setups. 
  Avoid verifying too much in each test. Fixtures which are too large and general
  not only take a while to comprehend but also hide the link between cause and effect.
  </p>
</div>

<div class="notes">
 <ul>
  <li>This another large topic. See <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a>
  for more details.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Behaviour Smell: Slow Tests</h1>
<blockquote>
<p>
"The tests take too long to run."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Direct Costs To The Developer</li>
  <li>Indirect Costs To The Project</li>
</ul>

<div class='handout'>
  <p>
  Slow tests really are a killer. 
  </p><p>
  Though the cost of writing tests can be seen as an investment, the cost of waiting for tests 
  to run is much harder to justify. No manager - especially a senior one - likes to see a developer 
  surfing the net, reading a paper or chatting with a collegue about the price of bread, even if it's 
  just dead time whilst the tests are running. 
  </p><p>
  The indirect effects are often more insidious. They offer a strong disincentive to running 
  the test suite regularly. In turn, this means that developers wait longer before integration
  their code. 
  </p><p>
  Infrequent code integration is major cause of delays. Developers find themselves idle waiting
  for other to commit code they rely on, or code is committed whilst they are waiting for the 
  test suite to finish. The volume of code changed between runs of the test suite is larger,
  making it more difficult to isolate which change caused the problem.
  </p><p>
  Slow tests are an area where <a href='#testdouble'>Test Doubles</a> can be of great value.
  It's exceptionally rare (on modern machines, outside numeric computing) for the actual 
  code to take long to execute. Typically, the time goes in heavyweight setup, tear down
  and data access which involve IO or extensive object creation. Substituting light weight
  doubles for heavy weight <abbr title='depended-on components'>DOCs</abbr> is the easiest
  way to reduce these costs. 
  </p>
</div>

<div class="notes">
 <ul>
  <li>
Access to middleware or the data base is a very common cause of <cite>Slow Tests</cite>.
    <ul>
      <li>
An overreliance on this kind of test may indicate an issues with developer test writing
skill levels. More training may be required.
      </li>
      <li>
It is generally best to separate out all tests of this kind and run them on a continuous
integration server.
      </li>
      <li>
Careful consideration should be given to the approach taken to integration testing. 
For example, asking developers to write integration tests using standard unit testing 
libraries may not be the most effect way to automate this kind of test.
      </li>
     </ul>
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->














<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='testdouble'>Pattern - Test Double</a></h1>
<blockquote>
<p>
"How can we verify logic independently when code it depends on is unusable?<br/>
How can we avoid Slow Tests?<br/>
We replace a component on which the SUT depends with a 'test specific equivalent'."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>A <em>Test Double</em> substitutes for an authentic DOC</li>
  <li>There are lots of reasons why a <em>Test Double</em> might be used</li>
</ul>

<div class='handout'>
  <p>
  A test double is an imposter for a depended-upon-component. The double presents an API
  compatible with the authentic dependency but differs in behaviour.
  </p>
  <p>
  There are lots of reasons why test doubles might be used. 
  Most of these will be covered in detail in later patterns.
  </p>
  <p>
  Within a test, test doubles may be used for used for different purpose
  and even the same double may play a number of roles. This means that it's very easy for
  developers to loose clarity about the purpose of a particular double. This often leads
  to unmaintainable, brittle tests. A consequence is that particular care needs to be taken
  to ensure that tests involving doubles are clearly documented and understandable.
  </p><p>
  There are so many ways that Test Doubles are useful that this becomes the problem.
  The reason why developers decided to use a test double - the role that it was 
  intended to play - is often very hard to diagnose. 
  </p><p>
  Many <a href='#mocktools'>mocking</a> tools are versatile and powerful enough to 
  create test doubles useful in a wide variety of situations. This often leads
  to problems with 
  <cite><a href='#hightestmaintenancecost'>High Test Maintenance Costs</a></cite>
  unless the different roles are clearly understood by developers and clearly
  documented in the test. 
  </p><p>
  When mixing <abbr title='Object Oriented'>OO</abbr>
  <cite><a href='#behaviourverification'>Behaviour Verification</a></cite> with 
  other <cite>Test Doubles</cite>, the same object may - at different times - be
  playing different roles. At some times, it will just be feeding lines to the
  subject but at others it will be actively monitoring the interaction.
  </p><p>
  A maintain needs to be understand which parts of the interaction are just scene
  setting and which are crucial parts of the dialogue. It is all too easy just to 
  lazily insist that all parts of the interaction are important.
  </p>
</div>

</div>
<!--  
END OF SLIDE 
-->









<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='dummy'>Test Double: Dummy Object</a></h1>
<blockquote>
<p>
"Dummy objects are passed around but never actually used. <br/>
Usually they are just used to fill parameter lists.."
</p>
</blockquote>
<div class='cite'><p><a href='#mocksarentstubs'><cite>Martin Fowler</cite></a></p></div>

<ul class='incremental'>
<li>A Simple Dummy</li>
<li>Too often overlooked</li>
</ul>

<div class='handout'>
  <p>
A <em>Dummy Object</em> is the simplest <a href='#testdouble'>Test Double</a>.
It's just used to make up the numbers in the parameters and isn't expected to 
be called.
  </p><p>
This expectation can - of course - cause problems for maintainability. It may 
be that a required behaviour change means that a parameters will now be 
called. Developers of tests should indicate clearly their intention
and name appropriately. 
  </p>
</div>

<div class="notes">
 <ul>
  <li><a href='#mocksarentstubs'>Mocks Aren't Stubs</a> explains the differences between
  dummies, stubs and mocks well, though the use of language differs just a little</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='teststub'>Test Double: Test Stub</a></h1>
<blockquote>
<p>
"How can we verify logic independently when it depends on<br/>
indirect inputs from other software components?<br/>
We replace a real object with a test-specific object that feeds the<br/>
desired inputs into the system under test."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
<li>Variation: Responder</li>
<li>Variation: Saboteur</li>
<li>Variation: Temporary Test Stub</li>
<li>Variation: Entity Chain Snipper</li>
</ul>

<div class='handout'>
  <p>
  A <em>Test Stub</em> is a substitute for a <abbr title='Depended-on Component'><a href='#doc'>DOC</a></abbr>
  injected to allow the fixture greater control over the indirect interactions of the <a href='#sut'>subject</a>.
  It's often hard or impossible to persuade the authentic implementation to behaviour as required.
  </p><p>
  Using an authentic implementation may be <a href='#fragiletest'>Fragile</a>. If the behaviour of that object
  (or some component it uses) changes, then it may not interact as expected by the test and so break it.
  Providing the intent of the test was not to include the integration of these components then this
  is an unexpected failure. 
  </p><p>
  When using authentic objects as stubs, it is useful to remember to document their purpose.
  </p><p>
  There are several common variations.
  </p><p>
  A <em>Responder</em> injects standard valid indirect inputs.
  </p><p>
  A <em>Saboteur</em> injects invalid indirect inputs. This allows error paths to be tested.
  </p><p>
  When developing inside-out (as is often encountered in <a href='#tdd'>TDD</a>), authentic
  implementations may not be yet available for many 
  <abbr title='Depended-on Component'><a href='#doc'>DOC</a></abbr>. A <em>Temporary Test Stub</em>
  stands in for components which are yet to be created. Sometime, these will be replace by
  authentic implementations later but often they are retained.
  </p><p>
  An <em>Entity Chain Snipper</em> is a special <em>Responder</em> which stubs out a complex
  object graph for quicker <a href='#fixture'>Fixture</a> construction.
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  <a href='#mocktools'>Mock Toolkits</a> are an easy way to create that can feed indirect 
  inputs to the <em>subject</em>. However, when stubbing, ensure that behaviour verification
  is turned off completely.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='fake'>Test Double: Fake Object</a></h1>
<blockquote>
<p>
"How can we verify logic independently when depended-on objects<br/>
cannot be used?<br/>
How can we avoid Slow Tests?<br/>
We replace a component that the SUT depends on with a much lighter-weight implementation."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ul class='incremental'>
  <li>Variation: Fake Database</li>
  <li>Variation: In-Memory Database</li>
  <li>Variation: Fake Web Service</li>
  <li>Variation: Fake Service Layer</li>
</ul>

<div class='handout'>
  <p>
A <em>Fake Object</em> is a lightweight implementation prividing similar functionality
to the original at a reduced cost. Like a <a href='#teststub'>Test Stub</a>, it substitutes
for a <a href='#doc'>DOC</a>. Whereas a <em>Test Stub</em> only sketches what little
implementation is required, a <em>Fake Object</em> is an implementation.
  </p>
  <p>
<cite>Fake Objects</cite> are generally underused for the main reason that they usually involve
an investment upfront which is only gradually paid back over time. Unfortunately,
usually when it becomes clear that a <em>Fake Object</em> is needed, the work required 
will be multiplied by the number of existing tests that will need to be rewritten.
  </p><p>
This makes appropriate consideration of <em>Fake Objects</em> a management issue for
Agile projects. Early in the project, when perhaps requirements and designs are 
still too fluid, time assigned to the development of judicious <em>Fake Objects</em> 
may well pay for itself may times over.
  </p><p>
Object source software is a great resource to mine when creating <em>Fake Objects</em>,
not simply because there is no licensing to worry about but forking the source really cuts
the effort required. Especially useful are embeddable server ideally with an in-memory
mode. Typical use cases are cut-down servers of all kinds: web service, LDAP, SQL database.
  </p>
  <p>
For projects with layered architectures, creating Fake service layers is often a good investment.
Real implementations typically conceal a heavyweight system behind a slim Facade.
This usually results in tests which are <a href='#slowtest'>quicker</a> and less
<a href='#fragiletest'>fragile</a>.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Some examples of embeddable open source software:
    <ul>
      <li><a href='http://www.mortbay.org/jetty/'>Jetty</a></li>
      <li><a href='http://www.h2database.com/html/main.html'>H2 Database</a></li>
      <li><a href='http://activemq.apache.org/'>ActiveMQ (JMS)</a></li>
      <li><a href='http://directory.apache.org/'>Apache Directory (LDAP)</a></li>
    </ul>
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->










<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='testspy'>Test Double: Test Spy</a></h1>
<blockquote>
<p>
"How do we implement Behaviour Verification?<br/>
How can we verify logic independently when it has indirect
outputs to other software components?<br/>
We use a Test Double to capture the indirect output calls<br/>
made to another components by the SUT for later verification by the test."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ol class='incremental'>
  <li>Substitute a <em>Test Spy</em> for a <a href='#doc'>DOC</a></li>
  <li>Exercise the <a href='#sut'>subject</a> whilst the <em>Test Spy</em> records</li>
  <li>Verify the recorded interactions</li>
</ol>

<div class='handout'>
  <p>
  This is the first encounter with a <a href='#testdouble'>Test Double</a> that is used
  only for <a href='#behaviourverification'>Behaviour Verification</a>. Though 
  <em>Behaviour Verification</em> is popularly associated with  
  <a href='#mockobject'>Mock Object</a>, this is not the only possible approach.
  <em>Test Spies</em> have been around a lot longer than <em>Mock Objects</em>.
  </p><p>
The essential idea is easy:
  </p>
  <ol>
    <li>
Develop a <em>Test Spy</em> that can be substituted
for a <abbr title='depended-on object'><a href='#doc'>DOC</a></abbr> and which
records interactions of interest
    </li>
    <li>
    Exercise the <a href='#sut'>subject</a> whilst the <em>Test Spy</em> records
    </li>
    <li>
    Verify the results
    </li> 
  </ol>
  <p>
  This sequence should be familiar to those developers who use 
  <a href='#stateverification'>State Verification</a> which may be of some advantage.
  However, in general <em>Behavioural Verification</em> is sufficiently different
  to warrent training for anyone who isn't familiar with it.
  </p><p>
<em>Test Spies</em> are typically hand crafted and used sparingly since (in most
<abbr title='Object Oriented'>OO</abbr> languages) there seem to be difficulties
making them into good libraries. When used in this way, tests seem to be more
readable (though this may have more to do with the care that was taken and time
invested rather than anything innate about this approach).
  </p>
</div>

<div class="notes">
 <ul>
  <li>A spy when the record is to be verified, a mock object when expectations are set.</li>
 </ul>
</div>
</div>




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='mockobject'>Test Doubles: Mock Objects</a></h1>
<blockquote>
<p>
"How do we implement Behaviour Verification for indirect outputs of the SUT?<br/>
How can we verify logic independently when it depends on indirect inputs
from other software components?<br/>
We replace an object on which the SUT depends on with a test-specific object that verifies 
it is being used correctly by the SUT."
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<ol class='incremental'>
<li>Expectations before, not verification after</li>
</ol>

<div class='handout'>
  <p>
  <em>Mock Objects</em> are used a little differently. Unlike a <a href='#testspy'>Test Spy</a>
  which just records what goes on, a <em>Mock Object</em> is loaded with expectations before
  the test runs and verifies interactions as the test proceeds to exercise the <a href='#sut'>subject</a>.
  When the exercise has finished, a final call allows the test to fail if any interactions have been
  missed.
  </p>
</div>

<div class="notes">
 <ul>
  <li>
  When a test has too many expectations, it does not effectively communicate it's intent.
  One common cause is that <em>Mock objects</em> are used when <em>Stubs</em> are a 
  better choice.
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->







<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Test Doubles: Implementation Patterns</h1>
<blockquote>
<p>
"How do we tell a Test Double what to return or expect?"
</p>
</blockquote>
<div class='cite'><p><a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a></p></div>
<p>A Question Of Reusability</p>
<ul class='incremental'>
<li>Hard Coded Test Double</li>
<li>Configurable Test Double</li>
</ul>

<div class='handout'>
  <p>
  Reusability is the key difference between the two main implementation categories. A hard coded
  double is really tied to a limited number of tests sharing similar fixtures. Configurable
  doubles can be reused more widely, at the expense of the added complexity which comes from 
  their lack of specivity.
  </p>
  <p>
  There are quite a few ways commonly used to create <em>Test Doubles</em>.  For discussions of their
  merits see <a href='#xunittestpatterns'><cite>xUnit Test Patterns</cite></a>.
  </p>
  <ul>
  <li>Hard Coded
    <ul>
      <li>A standalone class</li>
      <li>A subclass of the authentic <abbr title='Depended-On Component'><a href='#doc'>DOC</a></abbr></li>
      <li>The test class itself</li>
      <li>An inner class of the test class</li>
    </ul>
  </li>
  <li>Configurable by
    <ul>
      <li>A configuration mode allowing the test to teach what to expect</li>
      <li>An API</li>
      <li>Hand crafted custom implementation</li>
      <li>Static generation</li>
      <li>Dynamic generation</li>
    </ul>
  </li>
  </ul>
  <p>
  Not only are there quite a number of different roles filled by <em>Test Doubles</em> but there
  are lots of differents way to implement them. Most combinations of implementation strategy and
  role are possible.
  </p>
</div>

<div class="notes">
 <ul>
  <li>When using a configurable <em>Test Double</em>, it often becomes difficult to understand 
  the test clearly and quickly. Remember to comment the <em>How</em>.</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->









<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Mock Object Toolkits...</h1>
<p>The Swiss Army Knife of Developer Testing</p>
<ul class='incremental'>
  <li>Lots Of Different <a href='tools'>Types</a></li>
  <li>Powerful</li>
  <li>Flexible</li>
  <li>Dangerous...</li>
  <li>...to the unwary</li>
</ul>

<div class='handout'>
  <p>
  <em>Mock Object Toolkits</em> make it easy and quick to create <a href='#testdouble'>Test Doubles</a>.
  </p>
  <p>
Though developed specifically for <a href='#behaviourverification'>Behaviour Verification</a>
using <a href='#mockobject'>Mock Objects</a>, 
the modern Mock Object toolkit is the Swiss Army Knife of developer testing.
  </p>
  <ul>
    <li>
Like a Swiss Army Knife, there are lots of different types, each claiming to be the original and best. 
    </li><li>
Like a Swiss Army Knife it is powerful at it's basic function (<em>Behaviour Verification</em>)
    </li><li>
Like a Swiss Army Knife it is flexible enough to be used in a number of roles  
    </li><li>
Like a Swiss Army Knife it is dangerous in the hands of anyone doesn't know enough to use it safely
    </li>
  </ul>
</div>

<div class="notes">
 <ul>
  <li>
  Developers of <em>Mock Toolkits</em> often naively assume that users will restrict their
  usage 
  </li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->









<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>...Toolkits Make Every Test Double A Mock Object</h1>
<ul class='incremental'>
  <li>Obscuring Intent</li>
  <li>Increasing Fragility</li>
</ul>

<div class='handout'>
  <p>
  Once a developer knows a <em>Mock Object Toolkit</em> well, the temptation is to save time by
  using it for every test.
  </p><p>
  The problem is that though <em>Mock Object Toolkits</em> make it easy to make <em>Test Doubles</em>
  they make every kind of <em>Test Double</em> act as a <a href='#mockobject'>Mock Object</a>.
  <a href='#teststub'>Stubs</a>, <a href='#dummy'>dummies</a> and <a href='#fake'>fakes</a> fill
  different roles in the drama. This <a href='#obscure'>obscures</a> the intention of the test
  by hiding the behaviour being verified, and makes the test more <a href='#fragiletest'>fragile</a>
  by extending the number of behaviour changes that break the test beyond the minimum intended 
  to be tested.
  </p><p>
  In the end, though, it's simply a question of poor test quality. Toolkits are just tools.
  </p><p>
  Developers can study patterns, learn how to analyse their tests and name appropriately. 
  They can invest in good fixture to allow good coverage to be easily coded. They can clearly 
  document their intentions.
  </p>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<blockquote>
<p>
This is a talk about the tests that developers write, <br/>
and how - as developers - we can write better tests.
</p>
</blockquote>

<div class="notes">
 <ul>
  <li>Space for audience participation</li>
 </ul>
</div>
</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>So, What Is A Unit Test?</h1>
<ul class='incremental'>
<li>Sadly, time's beaten us...</li>
</ul>

<div class='handout'>
  <p>
  End on a light note.
  </p>
</div>
</div>
<!--  
END OF SLIDE 
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<div class='partition'>
<h1>End</h1>
</div>

<div class='handout'>
  <p>
  The end of this section. An epilogue follows.
  </p>
</div>

</div>
<!--  
END OF SLIDE 
-->




<!--  
END OF SLIDE 
-->
<!-- 
###############################################################################################
#
#
# EPILOGUE
#
#
###############################################################################################
-->




<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Reading</h1>

<ul>
  <li>
  <a name='xunittestpatterns' href='http://xunitpatterns.com/'>xUnit Test Patterns: Refactoring Test Code</a> 
  by <cite>Gerard Meszaros</cite>
  </li>
  <li>
  <a name='refactoring' href='http://martinfowler.com/books.html#refactoring'>Refactoring: Improving the Design of Existing Code</a> 
  by <cite>Martin Fowler</cite>
  </li>
  <li>
  <a name='designpatterns' href='http://c2.com/cgi/wiki?DesignPatternsBook'>Design Patterns: Elements of Reusable Object-Oriented Software</a> 
  by <cite>Erich Gamma</cite> <cite>Richard Helm</cite> <cite>Ralph Johnson</cite> <cite>John Vlissides</cite>
  </li>
  <li><a name='testdrivendevelopment' href='http://www.google.co.uk/books?id=gFgnde_vwMAC&printsec=frontcover&source=gbs_summary_r&cad=0'>Test-Driven Development: By Example</a> 
  by <cite>Kent Beck</cite>
  </li>
</ul>

<div class='handout'>
  <p>
  A huge debt is owed to <a href='#xunittestpatterns'>xUnit Test Patterns</a>. The design patterns, terminology and code smells
  described are described and explained in that book. It's only possible to cover a small 
  amount of the material contained in that comprehensive tome but hopefully your appetites may have been wet.
  Buy the book.  
  </p>
  <p>
  <a href='#designpatterns'>Design Patterns</a> needs no introduction. <a href='#refactoring'>Refactoring</a>
  is another influential classic. <a href='#testdrivendevelopment'>Test Driven Development</a> is just about 
  the best way to learn the basics of Agile development. Every developer should own a copy.
  </p>
</div>
</div>
<!--  
END OF SLIDE 
-->





<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Surfing</h1>
<ul>
<li><a name='bdd' href='http://dannorth.net/introducing-bdd'>Introducing BDD</a> by <cite>Dan North</cite></li>
<li><a name='mocksarentstubs' href='http://martinfowler.com/articles/mocksArentStubs.html'>Mocks Aren't Stubs</a> by <cite>Martin Fowler</cite></li>
<li><a name='codesmells' href='http://martinfowler.com/bliki/CodeSmell.html'>Code Smells</a> by <cite>Martin Fowler</cite></li>
<li><a href='http://www.jroller.com/robertburrelldonkin/entry/tdd_mocks_fakes_stubs'> The Language Of Testing: Dummies, Mocks, Fakes And Stubs</a> 
<br/>By <cite>Robert Burrell Donkin</cite></li>
<li><a href='http://www.jroller.com/robertburrelldonkin/entry/mocking_stubs_jmock_considered_harmful'>JMock: Good But Could Do Better</a>
By <cite>Robert Burrell Donkin</cite></li>
</ul>

<div class='handout'>
  <p>
Dan North's <a href='#bdd'>article</a> which introduced <cite>Behaviour Driven Development</cite> packs a huge number
of ideas into a couple of pages.
  </p>
  <p>
  Martin Fowler's <cite>Mocks Aren't Stubs</cite> is a good place start to reading about test doubles. BDD has a tendency
  to be technology lead. There are some great libraries but are often applied with insufficient thought. 
  Take a step back and think first.
  </p>
  <p>
  <a href='#codesmells'>Code Smells</a> is a short - but definitive - description of the nature of a code smell.
  <a href='#xunittestpatterns'>xUnit Test Patterns</a> and <a href='#refactoring'>Refactoring</a> devote much
  more space to more detailed descriptions. Worth reading.
  </p>
</div>
</div>
<!--  
END OF SLIDE 
-->








<!--  
START OF SLIDE 
-->
<div class="slide">
<h1>Tools</h1>

<ul>
  <li>
    <a name='cunit' href='http://cunit.sourceforge.net/'>CUnit</a> is an idiomatic <code>C</code>
  unit test framework.
  </li>
    <li>
    <a name='junit' href='http://junit.org/'>JUnit</a> is an idiomatic <code>Java</code>
    unit test framework.
  </li>
  <li>
  <a name='nunit' href='http://www.nunit.org/'>NUnit</a> is an idiomatic <code>.NET</code>
  unit test framework
  </li>
  <li>
    <a name='sunit' href='http://sunit.sourceforge.net/'>SUnit</a> is an idiomatic <code>Smalltalk</code>
  unit test framework.
  </li>
  <li>...And So On...</li>
</ul>

<div class='handout'>
  <p>
  The <em>xUnit</em> family is large indeed. This is a just a sample. The tools are out there...
  </p>
</div>

<div class="notes">
 <ul>
  <li>Opportunity for audience participation (if time allows) by naming tests<li>
 </ul>
</div>

</div>
<!--  
END OF SLIDE 
-->


<!--  
START OF SLIDE 
-->
<div class="slide">
<h1><a name='mocktools'>Mocking Toolkits</a></h1>
<ul>
  <li>
    <a href='http://www.easymock.org/' name='easymock'>EasyMock</a>
  </li>
  <li>
  <a href='http://jmock.org' name='jmock'>JMock</a>
  </li>
  <li>
  <a href='http://code.google.com/p/mockito/' name='mockito'>Mockito</a>
  </li>
  <li>
  <a href='http://code.google.com/p/googlemock/' name='googlemock'>GoogleMock</a>
  </li>
  <li>...</li>
</ul>
<div class='handout'>
  <p>
  Take your pick. Again, this is a long way from being an comprehensive list.
  </p>
</div>

<div class="notes">
 <ul>
  <li>Opportunity for audience participation</li>
 </ul>
</div>

</div>
<!--  
END OF SLIDE 
-->






<!--  
START OF ACKNOWLEDGEMENTS 
-->
<div class="slide">
<h1>Thanks</h1>
<ul>
<li>For listening</li>
<li>For inviting me</li>
<li><a name='S5'>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
Based on
<cite>Test Doubles: An Introduction To Unit Test Patterns</cite>
  by 
<a href="http://www.opentalkware.org" >OpenTalkWare</a>.
 Original source is <a href="http://opentalkware.googlecode.com/svn/talk/" rel="dc:source">available</a> under
    <a rel="license" href="http://creativecommons.org/licenses/by/3.0/">CC-BY</a>. UI based on 
    <a href='http://www.meyerweb.com/eric/tools/s5/credits.html'>S5</a> which is public domain.
</p>
<!-- 
END ATTRIBUTION
-->
</a>
</li>
</ul>

<div class='handout'>
  <p>
<!-- 
START ATTRIBUTION 

This section should be retained by derivative works.

See http://creativecommons.org/licenses/by/3.0/

-->
  <a href="http://www.opentalkware.org" >OpenTalkWare</a> contributors to <cite>Test Doubles: An Introduction To Unit Test Patterns</cite>
   include Robert Burrell Donkin.
<!-- 
END ATTRIBUTION
-->
  </p>
</div>

</div>
<!--  
END OF ACKNOWLEDGEMENTS
-->









</div>

</body>
</html>
